Некоторое время назад компания VMware инициировала Project Serengeti, целью которого было обеспечение возможности запуска кластеров Apache Hadoop на виртуальной платформе (в частности, VMware vSphere). Это одна из первых серьезных инициатив VMware в сегменте Big Data.
Совсем недавно была выпущена бета-версия расширений VMware vSphere Big Data Extensions v1.0 Beta, которые позволяют применить все наработки Serengeti для создания виртуальных машин с Hadoop на борту. Эти расширения обеспечивают жизненный цикл Hadoop на платформе VMware vSphere и позволяют отслеживать потребляемые ими ресурсы.
Возможности VMware vSphere Big Data Extensions v1.0 Beta:
Графический интерфейс Big Data Extensions. Он позволяет создавать, масштабировать и удалять кластеры Hadoop. Кроме того, доступен отдельный мониторинг и контроль ресурсов этих виртуальных машин.
В целом, VMware заявляет, что Apache Hadoop исполняется в виртуальных машинах практически без потерь производительности (об этом можно почитать здесь):
Скачать VMware vSphere Big Data Extensions v1.0 Beta можно по этой ссылке.
Таги: VMware, vSphere, Hadoop, Big Data, Performance
Не так давно мы писали про средства управления питанием хост-серверов ESXi, которые имеются в VMware vSphere 5.1. Там мы рассматривали такую политику как Balanced - она разработана для того, чтобы максимально использовать переключения между состояниями P-states процессора в целях экономии энергии. Она обладает слегка большей инерционностью, чем обычное максимальное использование ресурсов процессора (High performance), но почти не влияет на производительность. Эта политика выставлена по умолчанию для серверов VMware ESXi 5.0 и более поздней версии.
Недавно на блоге VROOM! компании VMware появилось интересное исследование, посвященное механизмам управления питанием серверов ESXi. Как и обычно, в качестве инструмента для тестирования и создания нагрузки на хосты ESXi использовался продукт VMware VMmark, который и был разработан для тестирования производительности решений VMware на различных аппаратных платформах.
Сравнивались три подхода к управлению питанием:
Политика Performance - максимальное использование процессора за счет его поддержки в наивысшем P-state состоянии все время (то есть, по-сути политика энергосбережения отключена). При этом используются только 2 C-state состояния: С0 (running) и C1 (halted). Соответственно, данный режим выдает максимальную производительность, не имеет инерционности и потребляет больше всего энергии. Управляется эта политика BIOS'ом сервера.
Политика Balanced - сбалансированное энергопотребление за счет переключения между P-states. Эта политика управляется хостом ESXi.
Политика BIOS Balanced - функции энергосбережения, которые управляются на уровне BIOS сервера (например, Dell Active Power Controller).
Для тестирования производительности использовался стандартный подход VMmark, который предполагает создание возрастающих уровней нагрузки на хост-серверы (Tiles).
С точки зрения аппаратной платформы, использовалась следующая конфигурация:
4 сервера Dell PowerEdge R620
CPUs (на сервер): один Eight-Core Intel® Xeon® E5-2665 @ 2.4 GHz, Hyper-Threading enabled
Memory (на сервер): 96GB DDR3 ECC @ 1067 MHz
Host Bus Adapter: два QLogic QLE2562, Dual Port 8Gb Fibre Channel to PCI Express
Network Controller: один Intel Gigabit Quad Port I350 Adapter
Версия гипервизора: VMware ESXi 5.1.0
Дисковый массив: EMC VNX5700
62 флеш-диска (SSDs), RAID 0, сгруппированных в 3 x 8 SSD LUNs, 7 x 5 SSD LUNs и 1 x 3 SSD LUN
Средства управления: VMware vCenter Server 5.1.0
Версия VMmark: 2.5
Power Meters: три устройства Yokogawa WT210
Итак, что получилось. График очков VMmark (чем выше столбики - тем лучше). Результаты нормализованы к BIOS Balanced на уровне Tile 1:
Как мы видим, худшие результаты показывает политика BIOS Balanced.
Теперь посмотрим на результаты тестов по новой методике VMmark 2.5, позволяющей измерять производительность сервера на киловатт питания:
Как мы видим, политика Performance показывает самые низкие результаты (это логично, так как энергии потребляется много, а столько мощности не всегда требуется процессору), политика ESXi Balanced показывает результат на 3% лучше, а вот политика BIOS Balanced - аж на 20% лучше.
Кстати, интересны измерения потребления мощности при простаивающем процессоре:
Политика Performance потребляет 128 Вт
ESXi Balanced - 85 Вт
BIOS Balanced - тоже около 85 Вт
Казалось бы, почему тогда не использовать BIOS Balanced? А вот почему - при тестировании нагрузки приложений политика BIOS Balanced выдает огромные задержки (latency), негативно влияющие на производительность:
Таким образом, если снова вернуться к первому графику с обобщенными результатами, можно понять, что политика ESXi Balanced является наиболее оптимальной с точки зрения энергопотребления/производительности, поэтому-то она и установлена по умолчанию.
Таги: VMware, ESXi, Performance, vSphere, Hardware, Power
Мы уже писали о компании VMTurbo, выпускающей продукты для мониторинга и управления виртуальной инфраструктурой на базе платформ различных вендоров. На днях VMTurbo сделала бесплатным продукт Virtual Health Monitor, предназначенный для мониторинга гетерогенной инфраструктуры виртуализации.
Надо сказать, что Virtual Health Monitor - это несколько доработанная версия издания Community Edition продукта VMTurbo Operations Manager, являющегося основным коммерческим решением компании, предназначенным для управления виртуальной средой.
Высокоуровневыми возможностями VMTurbo Virtual Health Monitor являются:
Возможность отслеживания производительности компонентов виртуального датацентра и определение уровня его работоспособности
Мониторинг параметров и построение отчетов о виртуальных машинах и хост-серверах в любом количестве (то есть настоящая бесплатность, без ограничений)
Поддержка нескольких гипервизоров одновременно
Еженедельный анализ аппаратных мощностей для определения степени эффективности их использования, а также прогнозирование необходимых дополнительных мощностей
Virtual Health Monitor поставляется уже в виде готового виртуального модуля (Virtual Appliance), который можно разместить на следующих платформах (они же, соответственно, и поддерживаются продуктом):
VMware vSphere
Microsoft Hyper-V
RedHat Enterprise Virtualisation (RHEV)
Citrix XenServer
Virtual Health Monitor был выпущен в преддверии выхода решения VMturbo Operations Manager 4.0, которое будет поддерживать гибридные облака и иметь специальные модули сопряжения с хранилищами различных производителей.
Скачать Virtual Health Monitor можно по этой ссылке.
Этот документ рассказывает о том, как нужно конфигурировать стандартный образ Windows для использования в VDI-инфраструктуре Horizon View. Для администраторов есть советы о том, как сделать такой образ с помощью Microsoft Deployment Toolkit (MDT) или с использованием сценариев для оптимизации виртуальных машин.
Для различных операций по оптимизации Windows 7 и Windows 8 включены детальные шаги по созданию необходимой конфигурации. Обновленный шаблон для групповых политик Windows 8 (а Horizon View также поддерживает интерфейс Metro) позволяет регулировать различные настройки этой ОС еще более гибко. Также рассматривается модель загрузки Windows 8, когда стартуют только необходимые службы ОС, а остальные запускаются по мере необходимости (Triggered Start).
Некоторое время назад мы уже писали о том, что в VMware Horizon View 5.2 Feature Pack 1 появилась возможность организовать доступ к виртуальным ПК по протоколу Blast через браузер с поддержкой технологии HTML5.
Для этого на сервер VMware View Connection надо поставить специальный компонент HTML Access Web Portal, а на клиентские ПК - агенты HTML Access Agent.
Для доступа к своему ПК пользователь соединяется с VMware View Security Server, который соединяется с View Connection Server по протоколу Blast по порту 8443, а тот уже, в свою очередь, взаимодействует с виртуальными ПК пула по порту 22443 (см. тут):
При этом похоже, что Blast - это отдельный протокол в VMware View, а не просто проброс PCoIP через HTML5. Вот так это выглядит в мониторинге сессий View Administrator:
Напомним, что для работы функции HTML Access в виртуальных ПК посредством Blast на данный момент поддерживаются следующие браузеры:
Google Chrome 22 и выше
Internet Explorer 9 и выше
Safari 5.1.7 и выше
Firefox 16 и выше
Mobile Safari для iOS с iOS 6 и выше (через Unity Touch)
Ну и самое интересное. Поскольку Blast - это отдельная ветка протокола VMware, то при отображении виртуального ПК через браузер не работают следующие вещи:
Отсутствует Multimedia и Flash Redirection
Не работает универсальная печать через ThinPrint
Не работает перенаправление USB
Не работает звук в виртуальном ПК
Не работают веб-камеры
Нет возможности доступа с Android-устройств
Производительность Blast существенно ниже, чем для PCoIP-сессии через толстый клиент
Возможны проблемы совместимости в различных браузерах
В целом для многих окружений критичной является только производительность пользовательских сессий в сравнении с PCoIP-соединениями. Поэтому ждем в ближайшее время обратной связи от пользователей на эту тему.
В документе описаны лучшие практики посроения подсистемы хранения для инфраструктуры виртуальных ПК VMware Horizon View. Рекомендации касаются размещения базовых образов и пулов связанных клонов, протоколов хранения, систем хранения данных и методик улучшения производительности.
У компании VMware есть специализированное ПО для моделиирования рабочей нагрузки в VDI-среде - VMware View Planner 2.0. К сожалению, это средство доступно только партнерам VMware, однако умной голове не составит труда раздобыть его. Также, напомним, что мы уже писали о средствах тестирования VDI-нагрузок: VDI Sizing Tool и Login VSI.
View Planner поставляется в виде виртуального модуля (Virtual Appliance) в формате OVF, построенного на базе дистрибутива Linux Centos 5.x и требующего 2 GB памяти и один vCPU на виртуальную машину.
View Planner предназначен для генерации различных сценариев рабочей нагрузки виртуальных ПК, включая управление состояниями виртуальных машин, пользователями Active Directory, построение отчетов и прочее. Все это управляется через веб-интерфейс, присутствующий у виртуального модуля, включая службы Active Directory и конфигурации View Connection servers, контролируемые средствами развертываемых на них агентов.
Архитектурно решение VMware View Planner состоит из следующих компонентов:
Виртуальные ПК на хостах VMware ESXi.
Несколько клиентских виртуальных машин на хостах ESXi - используются для удаленного режима или пассивных тестов, т.е. те, откуда происходит доступ к виртуальным ПК.
View Planner можно запускать в трех различных режимах:
Remote mode - в этом случае для каждой тестируемой ВМ будет своя клиентская машина. Это самый затратный с точки зрения необходимых ресурсов способ тестирования, однако самый адекватный.
Passive Client mode - в этом режиме клиентских машин требуется меньше и они только пассивно принимают результаты вывода тестируемых машин, а последние генерируют нагрузку. Это позволяет снизить требования к нужным для тестирования ресурсам.
Local mode - в этом случае тесты исполняются только на десктопах, без клиентов. Это не учитывает сетевой трафик между ними, поэтому менее репрезентативно, зато и менее затратно.
Вот, например, как работает тест в режиме Remote mode:
Все данные о тестировании нагрузок хранятся в базе данных MySQL.
Модель нагрузки задается в виде блоков, каждый из которых создается под свою задачу для виртуальных ПК:
Пример рабочей нагрузки, генерируемой View Planner:
В качестве результатов работы View Planner вы получите следующие полезные параметры:
Время отклика в виртуальном ПК (Responce Time) - показатель QoS для пользователей
Статистики использования ресурсов (Resource stats)
Запускаем тест, получаем примерное число виртуальных ПК (пользователей), которые выдержит наша виртуальная инфраструктура с заданным показателем QoS (в данном случае время отклика - 1,5 секунды):
Из таблицы видно, что при заданной модели нагрузки наша VDI-инфраструктура с приемлемым показателем качества обслуживания будет выдерживать максимум ~130 пользователей. Не такого ли ответа на вопрос ожидают те из вас, кто планирует VDI-инфраструктуру у себя в организации?
Чтобы продолжить изучение полезного продукта VMware View Planner, рекомендую обратиться по следующим ссылкам:
На днях, на сайте проекта VMware Labs (у нас есть тэг Labs) появилась новая утилита DRMdiagnose, с помощью которой возможно просмотреть информацию о текущем состоянии ресурсов кластера и получить рекомендации по управлению ими.
DRM - это Distributed Resource Manager, основной компонент VMware vSphere, являющийся ядром механизма VMware DRS, который осуществляет балансировку ресурсов в кластере. Основное назначение утилиты DRMdiagnose - это предоставление информации о том, что произойдет с производительностью виртуальных машин и их вычислительными ресурсами, если настройки ресурсов (limit, shares, reservation) будут изменены для какой-то из виртуальных машин. Кроме того, эта утилита выдает рекомендации относительно того, что нужно сделать с ресурсами виртуальных машин по отношению к текущим назначенным ресурсам (уменьшить, увеличить).
Появилась эта утилита по той причине, что пользователи VMware vSphere не знали, что происходит с кластером и его производительностью при регулировании настроек выделения ресурсов для виртуальных машин. Утилита позволяет получить рекомендации относительно того, как можно изменить настройки ресурсов ВМ для достижения оптимальной производительности.
DRMdiagnose позволяет увидеть рекомендации в кластере наподобие таких:
Increase CPU size of VM Webserver by 1
Increase CPU shares of VM Webserver by 4000
Increase memory size of VM Database01 by 800 MB
Increase memory shares of VM Database01 by 2000
Decrease CPU reservation of RP Silver by 340 MHz
Decrease CPU reservation of VM AD01 by 214 MHz
Increase CPU reservation of VM Database01 by 1000 MHz
Для того, чтобы начать пользоваться DRMdiagnose, нужно скопировать в рабочую папку с утилитой снапшот кластера (drmdump), содержащий информацию о виртуальных машинах и их запросы на вычислительные ресурсы. Находится он вот тут:
vCenter server appliance: /var/log/vmware/vpx/drmdump/clusterX/
vCenter server Windows 2003: %ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\
vCenter server Windows 2008: %ALLUSERSPROFILE%\VMware\VMware VirtualCenter\Logs\drmdump\clusterX\
Сама утилитка может работать в трех режимах:
Default - если указан путь к drmdump, то выводятся все ВМ кластера, их назначенные ресурсы, а также запрашиваемые ресурсы.
Guided - если указан путь к drmdump и целевые параметры ресурсов ВМ, то утилита сгенерирует набор рекомендаций для их достижения.
Auto - если указан путь к drmdump, то будут сгенерированы рекомендации для самых несбалансированных ВМ (то есть ВМ, для которых разница между назначенными и запрашиваемыми ресурсами самая большая).
Выглядят снапшоты кластера вот так:
А вот так можно запустить утилиту в дефолтном режиме для вывода информации в файл output.txt:
Формат использования DRMdiagnose:
Работает DRMdiagnose только с VMware vCenter 5.1 и выше, скачать утилиту можно по этой ссылке.
Очень давно мы писали про тип виртуальных дисков Paravirtual SCSI (PVSCSI), который появился в VMware vSphere 4 и был создан для требовательных к ресурсам ввода-вывода нагрузок. На заре своего развития виртуальные диски типа PVSCSI не рекомендовались к использованию в качестве загрузочных, а также имели несколько серьезных багов, но широко тестировались в связи с тем, что показывали большую производительность, чем стандартный LSI SCSI.
Эту статью мы пишем, главным образом, здесь для того, чтобы сказать - уже можно. Виртуальные диски Paravirtual SCSI достаточно стабильно работают в VMware vSphere. В KB 1010398 мы видим матрицу поддержки дисков pvscsi для различных релизов VMware vSphere (обычные и boot-диски):
Guest operating system
Data Disk
Boot Disk
Windows Server 2008 R2 (64-bit only)
ESX/ESXi 4.0 Update 1, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 1, ESX/ESXi 4.1, ESXi 5.0
Windows Server 2008 (32 and 64 bit)
ESX/ESXi 4.X, ESXi 5.0
ESX/ESXi 4.0 Update 1, ESX/ESXi 4.1, ESXi 5.0
Windows Server 2003 (32 and 64 bit)
ESX/ESXi 4.x, ESXi 5.0
ESX/ESXi 4.x, ESXi 5.0
Windows 7 (32 and 64 bit)
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
Windows Vista (32 and 64 bit)
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
Windows XP (32 and 64 bit)
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
Red Hat Enterprise Linux (RHEL) 5 (32 and 64 bit) and all update releases
ESX/ESXi 4.X, ESXi 5.0
Not Supported
RHEL 6 (32 and 64 bit)
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
SUSE Linux Enterprise 11 SP1(32 and 64 bit) and later releases
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
Ubuntu 10.04 (32 and 64 bit) and later releases
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.0 Update 2, ESX/ESXi 4.1, ESXi 5.0
Distros using Linux version 2.6.33 or later and that include the vmw_pvscsi driver
ESX/ESXi 4.1, ESXi 5.0
ESX/ESXi 4.1, ESXi 5.0
В VMware vSphere/ESXi 5.1 поддерживается все то, что поддерживалось и в предыдущих версиях платформы.
Что же раньше были за баги с PVSCSI? Смотрим, например, в статье тут, отсылающей нас к KB компании Microsoft. Ошибка существовала для ОС Windows Server 2008 R2 и была критической, а устранена была только в VMware vSphere 5.0 Update 1, о чем есть KB 2004578.
Теперь о том, как поставить диск типа PVSCSI в качестве загрузочного для виртуальной машины на ESXi. Выбираем в vSphere Client контроллер типа VMware Paravirtual :
В настройках виртуальной машины добавляем виртуальный floppy-дисковод и указываем образ дискеты с драйвером PVSCSI, который лежит в папке vmimages->floppies (если там ничего нет, идем сюда):
Дальше при выборе диск для установки Windows указываем драйвер с дискеты:
Дальше ставим все как обычно. Если хочется запихнуть драйвер PVSCSI в кастомизированную ISO-шку, то вам сюда. И да, драйвер на образе дискеты от Windows Server 2008 прекрасно работает на Windows Server 2012, который, в свою очередь, работает на VMware vSphere 5.1.
В рамках Phase V (они величают свои изыскания "фазами") был опубликован 80-страничный документ "Antivirus impact and best practices on VDI", в котором они сравнивают производительность различных антивирусных решений в инфраструктуре VDI (традиционно рассматривалась платформа VMware View / vSphere).
КДПВ из какого-то исследования (есть в документе):
Поэтому детально сравниваются только 3 антивируса для VDI:
Microsoft
Forefront Endpoint Protection 2010 (Now System Center Endpoint Protection 2012)
McAfee
- Enterprise 8.8.0
- MOVE Multiplatform AV 2.x
- MOVE Agentless AV 2.5
Symantec
- Endpoint Protection 12.1
Странно, что обошли стороной компанию Trend Micro с ее весьма популярным, заточеннымспециально под виртуализацию, решением Deep Security. Ну а нам было бы интересно посмотреть, как ведет себя Касперский в среде VDI. Но чего нет, того нет.
Конечно же, в документе рассмотрены и варианты развертывания, когда антивирусный агент работает за пределами виртуальных машин (за счет механизма VMsafe и EPSEC API):
В конце там много всяких графиков без окончательного вывода о том, что же все-таки лучше. Поэтому смотрите сами.
На днях компания VMware провела целых два тестирования (тут и тут), целью которых было сравнение производительности виртуальных дисков VMDK и RDM виртуальных машин на платформе VMware vSphere 5.1. Напомним про предыдущие сравнения VMFS и RDM, где основной моралью был тот факт, что оба этих типа виртуальных дисков практически идентичны по производительности, поэтому их следует использовать только в случаях, когда требуется специфическая функциональность (например, кластеры MSCS и большие диски для RDM):
Итак, для первого тестирования использовалась следующая конфигурация:
В качестве нагрузки использовался тест DVD Store для приложения, симулирующего интернет-магазин на платформе mySQL 5.5. Также было задействовано несколько тестовых клиентов для создания реальной нагрузки.
Масштабируемость производительности под нагрузкой (OPM - это orders per minute):
Как видно из результатов, масштабируемость производительности при увеличении числа ВМ почти линейная, а результаты различных типов дисков - идентичны (на самом деле, VMDK показал себя на 1 процент быстрее RDM для 1-й ВМ и чуть медленнее для 4-х ВМ):
Затраты ресурсов CPU на обслуживание операций ввода-вывода также чуть-чуть (на тот же 1%) лучше в пользу VMDK:
Теперь обратимся ко второму исследованию. Там использовалась следующая тестовая конфигурация, выдающая 1 миллион IOPS на тестах:
Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: Two Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: Five QLogic QLE2562
Storage: One Violin Memory 6616 Flash Memory Array
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Configuration: Random, 4KB I/O size with 16 workers
Тут уже измерялась производительность в IOPS для виртуальных машин на платформе VMware vSphere 5.1. При этом варьировался размер блока ввода-вывода (I/O Size) и сравнивались VMDK диски в VMFS5 и RDM-тома (нагрузка - случайное чтение):
Здесь уже на тот же самый 1% выигрывает RDM (для тестов на I/O). В тестах на MB/s ситуация в одном тесте оказалась в пользу VMFS. Масштабируемость тут уже показана не совсем линейная, при этом завал кривой начинается после размера блока в 4 Кб (единственный и по умолчанию в vSphere 5.1).
Второй тест - 60% операций чтения и 40% операций записи:
Такой рост производительности на блоке в 4 Кб объясняется просто - массив, примененный в тестировании, использует размер блока 4 Кб.
Вывод обоих тестов - виртуальные диски VMDK и RDM практически идентичны с точки зрения производительности.
С приходом Нового года в продукте VMware vCenter, входящем в состав vSphere 5.1, была обнаружена ошибка, следствием которой является отображение за прошедший год статистик производительности (Performance history) только за последние 30 дней (декабрь).
Данная ошибка является следствием недоработок в хранимых процедурах БД vCenter Server, что приводит к удалению (purge) объектов базы данных, касающихся производительности. Исправления ошибки и никакого workaround'а пока нет.
С одной стороны, эти данные не являются критичными и, зачастую, не используются администраторами, однако различные продукты, которые используют исторические данные для анализа и планирования мощностей инфраструктуры виртуализации (Capacity Planning), не смогут уже выполнять свои функции адекватно.
Для получения информации об исправлении ошибки можно подписаться на KB 2042164.
Не так давно мы писали про то, как работает механизм динамического выравнивания нагрузки на виртуальные хранилища VMware Storage DRS. Напомним, что он работает на базе 2-х параметров хранилищ:
Заполненность - в этом случае SDRS выравнивает виртуальные машины для равномерного заполнения хранилищ.
Производительность - при использовании этих метрик SDRS старается динамически перенести виртуальные машины с более нагруженных по параметрам ввода-вывода хранилищ на менее загруженные.
Однако бывает так, что несколько виртуальных хранилищ (Datastores) располагаются на одних и тех же RAID-группах, а значит миграция хранилищ виртуальных машин между ними ничего не даст - суммарно бэкэнд-диски системы хранения будут испытывать ту же самую нагрузку.
Например, бесполезна (с точки зрения производительности) будет миграция с Datastore1 на Datastore2:
Раньше этот факт не учитывался механизмом SDRS в vSphere 5.0, что приводило к бесполезным миграциям в автоматическом режиме. Теперь ситуация изменилась к лучшему в версии vSphere 5.1.
Как многие знают, в VMware vSphere есть механизм Storage IO Control (SIOC), который позволяет измерять мгновенную производительность хранилищ (параметр latency - задержка команд ввода-вывода) и регулировать очередь HBA-адаптеров на хостах ESXi. Так вот, одна из техник SIOC Injection позволяет производить тестирование виртуальных хранилищ на наличие корреляции производительности между ними.
Делается это следующим образом: SIOC запускает тестовую рабочую нагрузку на случайно выбранном Datastore1, измеряет latency, а потом отдельно от него запускает нагрузку на другом Datastore2 и также смотрит на latency:
Это нужно для установления базового уровня производительности для этих виртуальных хранилищ. Потом SIOC запускает нагрузку одновременно на 2 этих хранилища и смотрит, что происходит с latency:
Если оба этих хранилища физических расположены на одних и тех же дисковых устройствах (как в нашем случае), то измеряемые latency в данном случае возрастут, что говорит о взаимной корреляции данных хранилищ в плане производительности.
Узнав про этот факт, Storage DRS не будет генерировать рекомендации по перемещению виртуальных машин между хранилищами Datastore1 и Datastore2:
Однако эти рекомендации перестанут генерироваться только на базе производительности, на базе заполненности хранилищ такие рекомендации останутся.
Достаточно давно, известный многим Duncan Epping писал о стартапе CloudPhysics, для которого он является техническим эдвайзором, и который выпускает продукт в виде виртуального модуля (Observer Virtual Appliance), систематизирующий информацию о количественных параметрах виртуальной среды VMware vSphere в виде карточек. На основе этих карточек можно составить заключение о существующих проблемах своей инфраструктуры виртуализации:
Для работы продукта потребуется установить OVA-модуль в своем окружении VMware vSphere, а дальше для просмотра параметров карточек можно использовать веб-консоль (для кого-то это может быть проблемой, так как данные посылаются на сервер CloudPhysics, однако они утверждают, что данные полностью обезличены).
Сами карточки формируются на базе опросов пользователей и всяческих голосований, которые проводятся, например, на конференциях VMworld. Вот примеры таких карточек:
Затем лучшие карточки, будучи реализованными технически, попадают в основной интерфейс продукта (при этом для появления новых карточек не обязательно обновлять виртуальный модуль в своей инсталляции).
Помимо этого есть всякие технические детали о виртуальной инфраструктуре, корелляции параметров и необычные метрики. В общем, для больших инсталляций в плане траблшутинга - штука интересная, попробуйте, это пока бесплатно.
Hypervisor: vSphere 5.1
Server: HP DL380 Gen8
CPU: 2 x Intel Xeon E5-2690, HyperThreading disabled
Memory: 256GB
HBAs: 5 x QLA2532
Storage: 2 x Violin Memory 6616 Flash Memory Arrays
VM: Windows Server 2008 R2, 8 vCPUs and 48GB.
Iometer Config: 4K IO size w/ 16 workers
Напомним, что на прошлом VMworld 2011 также была показана производительность в 1 миллион IOPS (300 000 для одной машины), но для хост-сервера VMware ESXi (суммарно от нескольких виртуальных машин).
Также из любопытных фактов, озвученных на VMworld 2012:
60% серверов уже являются виртуальными, VMware стремится к показателю 90% и более.
Число сертифицированных специалистов VMware VCP достигло 125 тысяч.
В VMworld 2012 приняли участие 20 000 специалистов.
Основная концепция на ближайшее будущее - "Software-defined data center" (по аналогии с приобретенной недавно концепцией компании Nicira - Software-defined networking). Предполагается, что ключевые позиции в этой концепции займут продукты VMware vSphere, vCloud Director, vCloud Connector, Site Recovery Manager, vCenter Operations и vFabric Application Director.
Больше об облачных инициативах VMware - в самое ближайшее время.
Если мы запустим утилиту esxtop, то увидим следующие столбцы (интересующее нас выделено красным):
Нас интересует 5 счетчиков, касающиеся процессоров виртуальных машин, с помощью которых мы сможем сделать выводы об их производительности. Рассмотрим их подробнее:
Счетчик %RUN
Этот счетчик отображает процент времени, в течение которого виртуальная машина исполнялась в системе. Когда этот счетчик для ВМ около нуля или принимает небольшие значение - то с производительностью процессора все в порядке (при большом его значении для idle). Однако бывает так, что он небольшой, а виртуальная машина тормозит. Это значит, что она заблокирована планировщиком ESXi или ей не выделяется процессорного времени в связи с острой нехваткой процессорных ресурсов на сервере ESXi. В этом случае надо смотреть на другие счетчики (%WAIT, %RDY и %CSTP).
Если значение данного счетчика равно <Число vCPU машины> x 100%, это значит, что в гостевой ОС виртуальной машины процессы загрузили все доступные процессорные ресурсы ее vCPU. То есть необходимо зайти внутрь ВМ и исследовать проблему.
Счетчики %WAIT и %VMWAIT
Счетчик %WAIT отображает процент времени, которое виртуальная машина ждала, пока ядро ESXi (VMkernel) выполняло какие-то операции, перед тем, как она смогла продолжить выполнение операций. Если значение этого счетчика значительно больше значений %RUN, %RDY и %CSTP, это значит, что виртуальная машина дожидается окончания какой-то операции в VMkernel, например, ввода-вывода с хранилищем. В этом случае значение счетчика %SYS, показывающего загрузку системных ресурсов хоста ESXi, будет значительно выше значения %RUN.
Когда вы видите высокое значение данного счетчика, это значит, что нужно посмотреть на производительность хранилища виртуальной машины, а также на остальные периферийные устройства виртуального "железа". Зачастую, примонтированный ISO-образ, которого больше нет на хранилище, вызывает высокое значение счетчика. Это же касается примонтированных USB-флешек и других устройств ВМ.
Не надо пугаться высокого значения %WAIT, так как оно включает в себя счетчик %IDLE, который отображает простой виртуальной машины. А вот значение счетчика %VMWAIT - уже более реальная метрика, так как не включает в себя %IDLE, но включает счетчик %SWPWT (виртуальная машина ждет, пока засвопированные таблицы будут прочитаны с диска; возможная причина - memory overcommitment). Таким образом, нужно обращать внимание на счетчик %VMWAIT. К тому же, счетчик %WAIT представляет собой сумму метрик различных сущностей процесса виртуальной машины:
Счетчик %RDY
Главный счетчик производительности процессора. Означает, что виртуальная машина (гостевая ОС) готова исполнять команды на процессоре (ready to run), но ожидает в очереди, пока процессоры сервера ESXi заняты другой задачей (например, другой ВМ). Является суммой значений %RDY для всех отдельных виртуальных процессоров ВМ (vCPU). Обращать внимание на него надо, когда он превышает пороговое значение 10%.
По сути, есть две причины, по которым данный счетчик может зашкаливать приведенное пороговое значение:
сильная нагрузка на физические процессоры из-за большого количества виртуальных машин и нагрузок в них (здесь просто надо уменьшать нагрузку)
большое количество vCPU у конкретной машины. Ведь виртуальные процессоры машин на VMware ESX работают так: если у виртуальной машины 4 vCPU, а на хосте всего 2 физических pCPU, то одна распараллеленная операция (средствами ОС) будет исполняться за в два раза дольший срок. Естественно, 4 и более vCPU для виртуальной машины может привести к существенным задержкам в гостевой ОС и высокому значению CPU Ready. Кроме того, в некоторых случаях нужен co-sheduling нескольких виртуальных vCPU (см. комментарии к статье), когда должны быть свободны столько же pCPU, это, соответственно, тоже вызывает задержки (с каждым vCPU ассоциирован pCPU). В этом случае необходимо смотреть значение счетчика %CSTP
Кроме того, значение счетчика %RDY может быть высоким при установленном значении CPU Limit в настройках виртуальной машины или пула ресурсов (в этом случае посмотрите счетчик %MLMTD, который при значении больше 0, скорее всего, говорит о достижении лимита). Также посмотрите вот этот документ VMware.
Счетчик %CSTP
Этот счетчик отображает процент времени, когда виртуальная машина готова исполнять команды, одна вынуждена ждать освобождения нескольких vCPU при использовании vSMP для одновременного исполнения операций. Например, когда на хосте ESXi много виртуальных машин с четырьмя vCPU, а на самом хосте всего 4 pCPU могут возникать такие ситуации с простоем виртуальных машин для ожидания освобождения процессоров. В этом случае надо либо перенести машины на другие хосты ESXi, либо уменьшить у них число vCPU.
В итоге мы получаем следующую формулу (она верна для одного из World ID одной виртуальной машины)
%WAIT + %RDY + %CSTP + %RUN = 100%
То есть, виртуальная машина либо простаивает и ждет сервер ESXi (%WAIT), либо готова исполнять команды, но процессор занят (%RDY), либо ожидает освобождения нескольких процессоров одновременно (%CSTP), либо, собственно, исполняется (%RUN).
Таги: VMware, vSphere, esxtop, ESXi, VMachines, Performance, CPU
Как известно, виртуализация требует дополнительных ресурсов сверх тех, которые потребляет непосредственно виртуальная машина. Это называют накладными расходами на виртуализацию (так называемый virtualization overhead). Оверхэд есть как для процессора (примерно 3-5 процентов на хост-сервере), так и для оперативной памяти.
При этом для оперативной памяти накладные расходы гипервизора зависят от количества виртуальных процессоров (vCPU) и объема оперативной памяти, выделенных виртуальной машине. Мы уже писали о накладных расходах по RAM для виртуальных машин в VMware vSphere 4, где использовались следующие средние значения:
В VMware vSphere 5 есть новая возможность, которая называется VMX Swap. При включении виртуальной машины гипервизор ESXi создает для нее vmx-процесс, управляющий различными структурами данных, под которые требуется физическая оперативная память. Ее объем, как было сказано, зависит от конфигурации ВМ - количества vCPU и RAM. Для снижения потребления этой памяти в ESXi 5.0 механизм VMX Swap создает swap-файл для сегментов данных процесса vmx, куда сбрасываются страницы памяти, но только в случае нехватки физической оперативной памяти на хосте.
VMX Swap создает файлы подкачки в директории с виртуальной машиной, через который и происходит загрузка и выгрузка страниц процесса vmx. Размещение этих файлов можно переопределить, добавив следующий параметр в расширенные настройки виртуальной машины:
sched.swap.vmxSwapDir
По умолчанию механизм VMX Swap включен и в критических ситуациях позволяет уменьшить overhead типичной виртуальной машины с 50 МБ до 10 МБ. Для виртуализации серверов такие порядки цифр может и не очень важны, зато для виртуализации настольных ПК (например, VMware View), где на одном сервере могут находиться десятки и даже сотни виртуальных машин, эта возможность может оказаться весьма кстати в условиях нехватки вычислительных ресурсов.
Если вы считаете, что ресурсов у вас достаточно и VMX Swap вам не нужен, можно его отключить, добавив значение FALSE в следующу расширенную настройку виртуальной машины:
sched.swap.vmxSwapEnabled
Ну а теперь посмотрим сколько оверхэда по памяти потребляет виртуальная машина уже в VMware vSphere 5 с включенным по умолчанию VMX Swap:
Эта информация уже из vSphere 5 Documentation Center. Как мы видим из таблицы, накладные расходы по памяти с учетом VMX Swap уже значительно меньше (в некоторых случаях до 8-9 раз). Как уверяют коллеги из VMware, в условиях недостатка ресурсов VMX Swap почти не влияет на производительность хост-сервера ESXi, ну а в условиях достатка - не влияет совсем.
На сайте Фрэнка Деннемана появилась отличная статья про механизмы "горячей" миграции хранилищ (Storage vMotion) и "горячей" миграции виртуальных машин (vMotion) в контексте их использования для одного хранилища (Datastore) или хоста ESXi в VMware vSphere. Мы просто не можем не перевести ее, так как она представляет большой интерес для понимания работы этих механизмов.
Начнем со Storage vMotion. Данная операция, очевидно, требует большой нагрузки как на хранилище, откуда и куда, переносятся виртуальные машины, так и на сам хост-сервер VMware ESXi. Особенно актуально это, когда хост или хранилище переходят в Maintenance Mode, и виртуальные машины массово начинают миграцию. В случае со Storage vMotion это создает колоссальную нагрузку на хранилище по вводу-выводу.
Для понимания затрат ресурсов на эти процессы Фрэнк вводит понятие "цены" (cost) начинающейся операции, которая не может превосходить количество доступных слотов на хосте или хранилище, выделенных под них. Наглядно это можно представить так:
Resource Max Cost - это максимальный объем в неких единицах (назовем их слотами), который находится в рамках пула доступных ресурсов для операции Storage vMotion. Для хоста ESXi емкость такого пула составляет 8 слотов, а цена операции Storage vMotion - 4 слота. Таким образом, на одном хосте ESXi могут одновременно выполняться не более 2-х операций Storage vMotion. Если выполняется одна операция - то занято 4 слота и 4 слота свободно (как для исходного, так и для целевого хранилища).
С хранилищем точно такая же система - но у него 128 слотов. Одна операция Storage vMotion для Datastore потребляет 16 слотов. Таким образом, на одном хранилище может выполняться 8 (128 / 16) одновременных операций Storage vMotion. Их могут инициировать, например, 4 хоста (по 2 операции максимально каждый). То есть, мы получаем следующую схему:
Все просто и понятно. Отметим здесь, что операция vMotion тоже потребляет ресурсы с Datastore - но всего 1 слот. Таким образом, на одном Datastore могут, например, выполняться 7 одновременных миграций Storage vMotion (7 * 16 = 112 слотов) и еще 16 миграций vMotion (112+16 = 128), задействующих ВМ этого Datastore.
Если вы не хотите, чтобы при переводе Datastore в Maintenance Mode на нем возникало сразу 8 одновременных миграций Storage vMotion и, как следствие, большой нагрузки, вы можете уменьшить пул слотов для хранилищ (для всех, а не для какого-то конкретно). Для этого нужно отредактировать конфигурационный файл vpxd.cfg на сервере VMware vCenter, который находится в папке:
Вбив значение 112, вы уменьшите максимальное число одновременных миграций Storage vMotion на Datastore до 7. На хосте ESXi менять размер пула слотов для Storage vMotion не рекомендуется (хотя такие секции можно добавить - это пробовали энтузиасты).
Про стоимость миграций vMotion для хостов ESX / ESXi 4.1 мы уже писали вот тут. На эту тему есть также статья KB 2001417. С тех пор в vMotion много чего изменилось, поэтому подтвердить актуальность для vSphere 5 пока не могу. Буду признателен, если вы напишете об этом в комментариях.
Не так давно мы упоминали о результатах тестирования решения для виртуализации настольных ПК предприятия VMware View 5, проведенного компанией Principled Technologies по поручению компании VMware. Продукт VMware View 5 в нем сравнивался с конкурирующим решением Citrix XenDesktop 5.5, при этом ПО от VMware выигрывало в производительности аналогу от Citrix для типовой нагрузки во многих категориях тестов.
VMware View 5 Performed better than or equal to Citrix XenDesktop 5.5 with equivalent settings on Login VSI workloads simulating common office applications
Посыл данного заголовка понятен - VMware View производительнее и круче.
Титульная страница отчета выглядит следующим образом:
В компании Citrix возмутились таким положением дел: "Как так? Они тестируют XenDesktop для одного десктопа и рабочей нагрузки в сферической локальной сети и выставляют это за результат реального тестирования. Непорядок!". Тогда в Citrix решили обратиться к парням из Principled Technologies и спросили "Что за дела, пацаны? Наше решение круче себя ведет, когда на предприятии сотни виртуальных ПК, доступ ко многим из них происходит через WAN-сети, да и вообще мы давно делаем продукт и свой протокол ICA/HDX, поэтому так быть не должно!".
Сообразительные ребята из Principled Technologies почесали репу и говорят: "А давайте мы вам сделаем тоже отчет! Там как раз про все это будет: и про WAN, и про то, что у вас есть технологии всякие оптимизации канала, и про все остальные ваши навороты". Citrix сказал: "А давайте!". И получился еще один документ, уже от апреля 2012 года, являющийся также результатом тестирования продуктов, но уже по заказу Citrix, с красивым заголовком:
Citrix XenDektop Provided a better remote user experience via WAN vs. VMware View 5
Видимо за прошлое исследование парням из Principled Technologies было немного стыдно, поэтому "vs. VMware View 5" они написали мелким шрифтом:
Посыл этого документа тоже понятен - Citrix круче VMware (причем если почитать, то даже если настроить View по Optimization Guide). Поэтому пользователям предлагается поломать голову над текстом и картинками обох исследований, которые радуют глаз своими разными подходами к оценке продуктов.
Посмотрим на графики первого исследования (по заказу VMware - справедливости ради отметим, что с Flash Redirection показан лучше XenDesktop):
Взглянем на второй документ (по заказу Citrix):
В итоге, что мы имеем: одна контора подготовила для двух конкурирующих вендоров отчеты, которые по-разному формируют отношение к их продуктам. Надо полагать, за это были заплачены деньги, ведь делаются такие вещи небесплатно. Поэтому все это напоминает один старинный анекдот. Ну а чуваки из PT свое получили.
Теперь мы ждем очередного задания для Principled Technologies, уже от VMware, в котором мы узнаем, почему же все-таки нужно использовать VMware при доступе через WAN. Непорядок же...
Как мы уже писали в одной из статей, в VMware vSphere 5 при работе виртуальных машин с хранилищами могут возникать 2 похожих по признакам ситуации:
APD (All Paths Down) - когда хост-сервер ESXi не может получить доступа к устройству ни по одному из путей, а также устройство не дает кодов ответа на SCSI-команды. При этом хост не знает, в течение какого времени будет сохраняться такая ситуация. Типичный пример - отказ FC-коммутаторов в фабрике или выход из строя устройства хранения. В этом случае хост ESXi будет периодически пытаться обратиться к устройству (команды чтения параметров диска) через демон hostd и восстановить пути. В этом случае демон hostd будет постоянно блокироваться, что будет негативно влиять на производительность. Этот статус считается временным, так как устройство хранения или фабрика могут снова начать работать, и работа с устройством возобновится.
В логе /var/log/vmkernel.log ситуация APD выглядит подобным образом:
2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_IssueCommandToDevice:2954:I/O could not be issued to device "naa.60a98000572d54724a34642d71325763" due to Not found
2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_DeviceRetryCommand:133:Device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update for failover with I/O blocked. No prior reservation exists on the device.
2011-07-30T14:47:41.187Z cpu1:2049)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.60a98000572d54724a34642d71325763" is blocked. Not starting I/O from device.
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:599:Retry world failover device "naa.60a98000572d54724a34642d71325763" - issuing command 0x4124007ba7c0
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:658:Retry world failover device "naa.60a98000572d54724a34642d71325763" - failed to issue command due to Not found (APD), try again...
2011-07-30T14:47:41.361Z cpu1:2642)WARNING: NMP: nmpDeviceAttemptFailover:708:Logical device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update...
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:599:Retry world failover device "naa.60a98000572d54724a34642d71325763" - issuing command 0x4124007ba7c0
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:658:Retry world failover device "naa.60a98000572d54724a34642d71325763" - failed to issue command due to Not found (APD), try again...
2011-07-30T14:47:42.361Z cpu0:2642)WARNING: NMP: nmpDeviceAttemptFailover:708:Logical device "naa.60a98000572d54724a34642d71325763": awaiting fast path state update...
Ключевые слова здесь: retry, awaiting. Когда вы перезапустите management agents, то получите такую вот ошибку:
Not all VMFS volumes were updated; the error encountered was 'No connection'.
Errors:
Rescan complete, however some dead paths were not removed because they were in use by the system. Please use the 'storage core device world list' command to see the VMkernel worlds still using these paths.
Error while scanning interfaces, unable to continue. Error was Not all VMFS volumes were updated; the error encountered was 'No connection'.
В этом случае надо искать проблему в фабрике SAN или на массиве.
PDL (Permanent Device Loss) - когда хост-серверу ESXi удается понять, что устройство не только недоступно по всем имеющимся путям, но и удалено совсем, либо сломалось. Определяется это, в частности, по коду ответа для SCSI-команд, например, вот такому: 5h / ASC=25h / ASCQ=0 (ILLEGAL REQUEST / LOGICAL UNIT NOT SUPPORTED) - то есть такого устройства на массиве больше нет (понятно, что в случае APD по причине свича мы такого ответа не получим). Этот статус считается постоянным, так как массив ответил, что устройства больше нет.
А вообще есть вот такая табличка для SCSI sense codes, которые вызывают PDL:
В случае статуса PDL гипервизор в ответ на запрос I/O от виртуальной машины выдает ответ VMK_PERM_DEV_LOSS и не блокирует демон hostd, что, соответственно, не влияет на производительность. Отметим, что как в случае APD, так и в случае PDL, виртуальная машина не знает, что там произошло с хранилищем, и продолжает пытаться выполнять команды ввода-вывода.
Такое разделение статусов в vSphere 5 позволило решить множество проблем, например, в случае PDL хост-серверу больше не нужно постоянно пытаться восстановить пути, а пользователь может удалить сломавшееся устройство с помощью операций detach и unmount в интерфейсе vSphere Client (в случае так называемого "Unplanned PDL"):
В логе /var/log/vmkernel.log ситуация PDL (в случае Unplanned PDL) выглядит подобным образом:
2011-08-09T10:43:26.857Z cpu2:853571)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:661: Path "vmhba3:C0:T0:L0" (PERM LOSS) command 0xa3 failed with status Device is permanently unavailable. H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.857Z cpu2:853571)VMW_SATP_ALUA: satp_alua_issueCommandOnPath:661: Path "vmhba4:C0:T0:L0" (PERM LOSS) command 0xa3 failed with status Device is permanently unavailable. H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.857Z cpu2:853571)WARNING: vmw_psp_rr: psp_rrSelectPathToActivate:972:Could not select path for device "naa.60a98000572d54724a34642d71325763".
2011-08-09T10:43:26.857Z cpu2:853571)WARNING: ScsiDevice: 1223: Device :naa.60a98000572d54724a34642d71325763 has been removed or is permanently inaccessible.
2011-08-09T10:43:26.857Z cpu3:2132)ScsiDeviceIO: 2288: Cmd(0x4124403c1fc0) 0x9e, CmdSN 0xec86 to dev "naa.60a98000572d54724a34642d71325763" failed H:0x8 D:0x0 P:0x0
2011-08-09T10:43:26.858Z cpu3:2132)WARNING: NMP: nmp_DeviceStartLoop:721:NMP Device "naa.60a98000572d54724a34642d71325763" is blocked. Not starting I/O from device.
2011-08-09T10:43:26.858Z cpu2:2127)ScsiDeviceIO: 2316: Cmd(0x4124403c1fc0) 0x25, CmdSN 0xecab to dev "naa.60a98000572d54724a34642d71325763" failed H:0x1 D:0x0 P:0x0 Possible sense data: 0x5 0x25 0x0.
2011-08-09T10:43:26.858Z cpu2:854568)WARNING: ScsiDeviceIO: 7330: READ CAPACITY on device "naa.60a98000572d54724a34642d71325763" from Plugin "NMP" failed. I/O error
2011-08-09T10:43:26.858Z cpu2:854568)ScsiDevice: 1238: Permanently inaccessible device :naa.60a98000572d54724a34642d71325763 has no more open connections. It is now safe to unmount datastores (if any) and delete the device.
2011-08-09T10:43:26.859Z cpu3:854577)WARNING: NMP: nmpDeviceAttemptFailover:562:Retry world restore device "naa.60a98000572d54724a34642d71325763" - no more commands to retry
Ключевое слово здесь - permanently.
Становится понятно, что в случае, когда устройство хранения (LUN) реально сломалось или удалено сознательно, лучше всего избежать ситуации APD и попасть в статус PDL. Сделать это удается хост-серверу ESXi не всегда - по прежнему в vSphere 5.0 Update 1 это обрабатывается в ограниченном количестве случаев, но в vSphere 5.1 обещают существенно доработать этот механизм.
Также есть Advanced Settings на хосте ESXi, которые позволяют управлять дальнейшей судьбой машины, которая оказалась жертвой ситуации PDL. В частности есть 2 следующие расширенные настройки (начиная с vSphere 5.0 Update 1) - первая в категории "Disk", а вторая в расширенных настройках кластера HA:
disk.terminateVMonPDLDefault - если эта настройка включена (True), то в ситуации PDL для устройства, где находится ВМ, эта машина будет выключена. Настройка задается на уровне хоста ESXi и требует его перезагрузки для ее применения.
das.maskCleanShutdownEnabled - это настройка, будучи включенной (True), позволяет механизму VMware HA приступить к восстановлению виртуальной машины. Соответственно, если она выключена, то HA проигнорирует выключение виртуальной машины в случае ее "убийства" при включенной первой настройке.
Рекомендуется, чтобы обе эти настройки были включены.
Все описанные выше механизмы могут очень пригодиться при построении и обработке сбоев в "растянутых кластерах" VMware HA, построенных между географически разнесенными датацентрами. Об этом всем детально написано в документе "VMware vSphere Metro Storage Cluster Case Study".
Таги: VMware, vSphere, Storage, Performance, Troubleshooting, HA, ESXi
Мы уже писали о новых возможностях VMware View 5.1 и, в частности, о технологии Storage Accelerator, которая использует кэш CBRC на чтение на стороне хоста VMware ESXi, чтобы быстрее отдавать блоки виртуальной машине напрямую из памяти, не обращаясь к хранилищу.
Как понятно из названия (Content Based Read Cache), технология Storage Accelerator позволяет оптимизировать ввод-вывод именно тогда, когда в среде виртуальных ПК у нас много операций чтения, которые происходят для множества связанных клонов, развертываемых из реплики View Compser. Таких показательных ситуаций две: Boot Storm (когда пользователи приходят на работу и одновременно включают свои ПК для доступа к своим виртуальным машинам) и Antivirus Storm (когда антивирус начинает шерстить файлы в гостевой ОС).
Интересные картинки по тестированию данной технологии обнаружились в одном из тестов Login VSI, которая проверила, как это работает на хосте со 143-мя связанными клонами виртуальных ПК для размера кэша CBRC размером в 2 ГБ. Работает это замечательно:
Как мы видим, к сотой минуте нагрузка улеглась и операции чтения стали уже не такими однородными. Для постоянных (persistent) дисков (т.е. тех, которые не развертываются из единого базового образа) технология CBRC тоже дает свои плоды:
Ну и здорово помогает нам View Storage Accelerator при антивирусном шторме, когда антивирусники большого количества виртуальных машин одновременно набрасываются на файлы гостевых ОС:
Ну и под конец напомним, что в качестве антивирусных решений в VDI-средах для оптимизации нагрузки нужно использовать решения с поддержкой VMsafe.
Мы уже недавно писали о метриках производительности хранилищ в среде VMware vSphere, которые можно получить с помощью команды esxtop. Сегодня мы продолжим развивать эту тему и поговорим об общей производительности дисковых устройств и сайзинге нагрузок виртуальных машин по хранилищам в виртуальной среде.
Как говорит нам вторая статья блога VMware о хранилищах, есть несколько причин, по которым может падать производительность подсистемы ввода-вывода виртуальных машин:
Неправильный сайзинг хранилищ для задач ВМ, вследствие чего хранилища не выдерживают такого количества операций, и все начинает тормозить. Это самый частый случай.
Перегрузка очереди ввода-вывода со стороны хост-сервера.
Достижение предела полосы пропускания между хостом и хранилищем.
Высокая загрузка CPU хост-сервера.
Проблемы с драйверами хранилищ на уровне гостевой ОС.
Некорректно настроенные приложения.
Из всего этого набора причин самой актуальной оказывается, как правило, первая. Это происходит вследствие того, что администраторы очень часто делают сайзинг хранилищ для задач в ВМ, учитывая их требования только к занимаемому пространству, но не учитывая реальных требований систем к вводу выводу. Это верно в Enterprise-среде, когда у вас есть хранилища вроде HDS VSP с практически "несъедаемой" производительностью, но неверно для Low и Midrange массивов в небольших организациях.
Поэтому профилирование нагрузки по хранилищам - одна из основных задач администраторов VMware vSphere. Здесь VMware предлагает описывать модель нагрузки прикладной системы следующими параметрами:
Размер запроса ввода-вывода (I/O Size)
Процент обращений на чтение (Read)
Процент случайных обращений (Random)
Таким образом профиль приложения для "типичной" нагрузки может выглядеть наподобие:
8KB I/O size, 80% Random, 80% Read
Само собой, для каждого приложения типа Exchange или СУБД может быть свой профиль нагрузки, отличающийся от типичного. Размер запроса ввода-вывода (I/O Size) также зависит от специфики приложения, и о том, как регулировать его максимальное значение на уровне гипервизора ESXi, рассказано в KB 1008205. Нужно просто в Advanced Settings выставить значение Disk.DiskMaxIOSize (значение в килобайтах). Некоторые массивы испытывают проблемы с производительностью, когда размер запроса ввода-вывода очень велик, поэтому здесь нужно обратиться к документации производителя массива. Если с помощью указанной настройки ограничить размер запроса ввода-вывода, то они будут разбиваться на маленькие подзапросы, что может привести к увеличению производительности подсистемы ввода-вывода на некоторых системах хранения. По умолчанию установлено максимальное значение в 32 МБ, что является достаточно большим (некоторые массивы начинают испытывать проблемы при запросах более 128 KB, 256 KB или 512KB, в зависимости от модели и конфигурации).
Однако вернемся к профилированию нагрузок по хранилищам в VMware vSphere. В одной из презентаций VMware есть замечательная картинка, отражающая численные характеристики производительности дисковых устройств в пересчете на шпиндель в зависимости от типа их организации в RAID-массивы:
Параметры в верхней части приведены для операций 100%-й последовательной записи для дисков на 15К оборотов. А в нижней части приведены параметры производительности для описанной выше "типичной" нагрузки, включая среднюю скорость чтения-записи, число операций ввода-вывода в секунду (IOPS) и среднюю задержку. Хорошая напоминалка, между прочим.
Теперь как анализировать нагрузку по вводу выводу. Для этого у VMware на сайте проекта VMware Labs есть специальная утилита I/O Analyzer, про которую мы уже писали вот тут. Она может многое из того, что потребуется для профилирования нагрузок по хранилищам.
Ну а дальше стандартные процедуры - балансировка нагрузки по путям, сторадж-процессорам (SP) и дисковым устройствам. Сигналом к изысканиям должен послужить счетчик Device Latency (DAVG) в esxtop, если его значение превышает 20-30 мс для виртуальной машины.
Мы уже писали об основных приемах по решению проблем на хостах VMware ESX / ESXi с помощью утилиты esxtop, позволяющей отслеживать все аспекты производительности серверов и виртуальных машин. Через интерфейс RCLI можно удаленно получать эти же данные с помощью команды resxtop.
Сегодня мы приведем простое объяснение иерархии счетчиков esxtop, касающихся хранилищ серверов VMware vSphere. Для того, чтобы взглянуть на основные счетчики esxtop для хранилищ, нужно запустить утилиту и нажать кнопку <d> для перехода в режим отслеживания показателей конкретных виртуальных машин (кликабельно). Данные значения будут представлены в миллисекундах (ms):
Если мы посмотрим на колонки, которые выделены красным прямоугольником, то в виде иерархии их структуру можно представить следующим образом:
Распишем их назначение:
GAVG (Guest Average Latency) - общая задержка при выполнении SCSI-команд от гостевой ОС до хранилища сквозь все уровни работы машины с блоками данных. Это, само собой, самое большое значение, равное KAVG+DAVG.
KAVG (Kernel Average Latency) - это задержка, возникающая в стеке vSphere для работы с хранилищами (гипервизор, модули для работы SCSI). Это обычно небольшое значение, т.к. ESXi имеет множество оптимизаций в этих компонентах для скорейшего прохождения команд ввода-вывода сквозь них.
QAVG (Queue Average latency) - время, проведенное SCSI-командой в очереди на уровне стека работы с хранилищами, до передачи этой команды HBA-адаптеру.
DAVG (Device Average Latency) - задержка прохождения команд от HBA адаптера до физических блоков данных на дисковых устройствах.
В блоге VMware, где разобраны эти показатели, приведены параметры для типичной нагрузки по вводу-выводу (8k I/O size, 80% Random, 80% Read). Для такой нагрузки показатель Latency (GAVG) 20-30 миллисекунд и более может свидетельствовать о наличии проблем с производительностью подсистемы хранения на каком-то из подуровней.
Как мы уже отметили, показатель KAVG, в идеале, должен быть равен 0 или исчисляться сотыми долями миллисекунды. Если он стабильно находится в пределах 2-3 мс или больше - тут уже можно подозревать проблемы. В этом случае нужно проверить значение столбца QUED для ВМ - если оно достигло 1 (очередь использована), то, возможно, выставлена слишком маленькая величина очереди на HBA-адаптере, и необходимо ее увеличить.
Для просмотра очереди на HBA-адаптере нужно переключиться в представление HBA кнопкой <u>:
Ну и если у вас наблюдается большое значение DAVG, то дело, скорее всего, не в хосте ESX, а в SAN-фабрике или дисковом массиве, на уровне которых возникают большие задержки.
Мы уже писали о новых возможностях VMware View 5.1 и новых клиентах, а сегодня поговорим о производительности этого решения для виртуализации настольных ПК предприятия. Прежде всего, напомним 2 основных документа, откуда можно узнать о том, какие техники использует VMware View и в каких моментах превосходит Citrix XenDesktop:
Теперь VMware View 5.1 идет еще дальше по сравнению с версией 5.0:
1. Появилась функция VMware View Storage Accelerator
Этот механизм позволяет использовать оперативную память сервера для кэширования наиболее часто используемых блоков данных виртуальных ПК, запрашиваемых с конечного устройства. Делается это средствами технологии Content Based Read Cache (CBRC), поддержка которой уже имеется в VMware vSphere 5.0. Эта штука, само собой, положительно влияет на скорость обмена данными с конечными устройствами и производительность операций ввода-вывода для виртуальных ПК, поскольку блоки запрашиваются напрямую из памяти хост-сервера:
Этот тест проводился для 50 виртуальных ПК с гостевой ОС Windows 7 и были достигнуты следующие результаты (по сравнению с ситуацией, когда CBRC отключен):
Увеличение до 80% пиковых IOPS
Увеличение на 45% средних IOPS
Увеличение пиковой скорости обмена с ПК до 65%
Увеличение средней скорости обмена с ПК на 25%
2. Оптимизация клиентов VMware View 5.1
Со стороны клиентов, компания VMware внесла множество улучшений, большинство которых сделано для увеличения производительности воспроизведения видео. По сравнению с версией View 5.0, клиенты View 5.1 дают следующий прирост в плане видео:
При этом отметим, что улучшения были сделаны как для x86, так и для ARM-клиентов.
3. Улучшения коммуникации клиент-сервер в View 5.1.
В механизмах коммуникации клиента VMware View 5.1 с виртуальной машиной на сервере было сделано множество умных и полезных улучшений, сводящихся к тому, что клиент чаще и быстрее взаимодействует с виртуальным ПК, что приводит к приросту производительности операций перетаскивания объектов (и гладкости их прорисовки), а также скроллинга. Вот, например, как отличается прорисовка кривых по протоколам PCoIP (View 5.1) и RDP:
В общем, если и раньше были объективные причины предлагать клиентам Citrix XenDesktop по причине высокой производительности протокола Citrix HDX, то теперь их практически не осталось. С каждой новой версией видно, что VMware инвестирует в PCoIP, а XenDesktop просто стоит дороже.
Похоже, что кто-то (после 5 лет разработки) наконец додумался до того, что нужно применять виртуализацию GPU со стороны сервера, чтобы реализовывать требовательные к графике нагрузки в инфраструктуре виртуальных ПК предприятия (VDI). 15 мая компания NVIDIA анонсировала скорую доступность платформы VGX, которая представляет собой модуль с четырьмя GPU и 16 ГБ памяти, который будет устанавливаться в сервер через стандартный разъем PCI Express (2 слота).
Платформа NVIDIA VGX основана на трех сущностях:
Плата NVIDIA VGX. Она имеет четыре GPU (каждый имеет 192 ядра NVIDIA CUDA) и 16 ГБ памяти и подключается к серверам через стандартный интерфейс PCI Express. Рассчитана на количество пользователей на сервер - до 100 штук.
NVIDIA VGX GPU Hypervisor. Этот программный компонент, который интегрируется в коммерческие гипервизоры (пока говоритя почему-то о Citrix XenServer), обеспечивая поддержку виртуализации GPU со стороны хост-сервера.
NVIDIA User Selectable Machines (USM). Эта опция позволяет компаниям предоставлять графические возможности индивидуальным пользователям в соответствии с их запросами. Эти возможности варьируются от реальных возможностей ПК, доступных со стандартной NVIDIA USM, до профессиональных функций 3D дизайна и проектирования с помощью GPU NVIDIA Quadro или NVIDIA NVS.
Характеристики платы VGX:
Теперь нам обещают новый уровнеь производительности в ПО для 3D-моделирования:
Воспроизведении видео:
И Windows Aero в виртуальном ПК:
Платформа NVIDIA VGX, включая новые платы NVIDIA VGX, а также компоненты NVIDIA GPU Hypervisor и NVIDIA USM, будет доступна через OEM и VDI партнеров NVIDIA уже в этом году. Ну что - посмотрим, штука интересная, и спрос на нее определенно есть.
Интересная штука обнаружилась среди средств управления и мониторинга инфраструктуры VMware vSphere - Cloud Resource Meter от компании 6fusion, которая специализируется на утилитах для облачных сред. Это такая штука, которая реализована в виде виртуального модуля (Virtual Appliance), позволяющая оценить облачную инфраструктуру vSphere "в попугаях", то есть в специальных единицах Workload Allocation Cube (WAC), потребляемых за час. Убеждают, что алгоритм этого WAC - не хухры-мухры, а patent pending.
Этот WAC - это шестимерная сущность, представляющая собой эталонную совокупность ресурсов, потребляемых виртуальной машиной в облаке, а именно:
Вот в количестве таких шестигранных кубиков вы и увидите каждую из виртуальных машин своего (или провайдерского) датацентра в реальном времени. Предполагается, что такая модель позволит наиболее адекватно обсчитать вычислительные мощности своего ЦОД (chargeback), вести учет и планировать вычислительные мощности. Облачные провайдеры и менеджеры корпоративных датацентров могут устанавливать параметры и цену такого "вака", что позволит понимать, сколько ресурсов есть в наличии и сколько будет стоить разместить то или иное приложение в облаке.
Для каждой машины ведется исторический учет потребляемых "вакочасов":
Авторы этой программулины утверждают, что алгоритм этих "ваков" был разработан еще в 2004 году для профилирования приложений под ESX 1.0, так что может стоит и посмотреть, что они с тех пор сделали, тем более, что есть бесплатная версия продукта Cloud Resource Meter. На данный момент он, правда, находится в бете, но поддерживает vSphere 4.1 и 5.0.
В преддверии выхода новой версии платформы для виртуализации настольных ПК VMware View 5.1, о котором будет объявлено 3 мая, продолжаем рассказывать о новых возможностях этого продукта. Сегодня продолжим разговор о функции Content Based Read Cache (CBRC), которая позволяет увеличить производительность операций чтения для наиболее часто читаемых блоков виртуальных ПК.
Как мы уже писали ранее, Content Based Read Cache - это функция кэширования в оперативной памяти хоста VMware ESXi, которая уже реализована в VMware vSphere 5. Убедиться в этом вы можете сами, открыв Advanced Settings на хосте:
Как мы видим из картинки, есть планка для CBRC размером в 2 ГБ, которую нельзя менять и есть текущее значение памяти, зарезервированной для кэша. Кроме того, есть настройка таймаута при загрузке хоста для дайджест-журнала SCSI, который хранит в себе хэш-таблицу блоков, которые учитывает кэш CBRC при их запросе от виртуальной машины.
Этот дайджест хранится в папке с виртуальной машиной в виде отдельного VMDK-файла:
То есть, при чтении виртуальной машиной блока с хранилища, он сначала ищется в кэше, и, если он там отсутствует, то он туда помещается и отдается виртуальной машине. Ну а если он в кэше есть - то сразу ей отдается. Соответственно, кэш CBRC увеличивает производительность при операциях чтения виртуальных машин хоста с одними и теми же блоками, что часто бывает в инфраструктуре VDI. Особенно это актуально при одновременной загрузке десятков виртуальных ПК, которая может вызвать так называемый Boot Storm. Посмотрите, как увеличивается интенсивность операций чтения при загрузке Windows ВМ, с которую может существенно "погасить" CBRC:
Надо отметить, что CBRC - это чисто хостовая фишка VMware vSphere, которую может поддерживать любое надстроенное VDI-решение (например, Citrix XenDesktop). А вот в VMware View поддержка CBRC будет идти под эгидой функции VMware View Storage Accelerator:
Как понятно из описанного выше, для такой поддержки практически ничего уже и делать не нужно - все есть в ESXi 5.0.
Во второй части заметки рассмотрим возможность VMware View Client Side Caching, которая представляет собой использование кэша в оперативной памяти устройств доступа к виртуальным ПК (тонкие и толстые клиенты с View Client) для картинки рабочего стола (а точнее, ее регионов). Эта возможность появилась уже в VMware View 5.0 и включена по умолчанию: 250 МБ памяти используется на клиенте, за исключением всяких Android и iOS-устройств.
Представьте, что вы просматриваете в виртуальном ПК PDF-документ. Рамка и контролы в ридере остаются на месте, а его содержимое скроллится в ограниченной области экрана. Вот для этого и нужен Client Side Caching - он позволяет закэшировать этот неизменяющийся фрагмент картинки экрана и не обращаться за ним к хосту и хранилищу. Это увеличивает производительность виртуального ПК до 30%.
Настраивается это просто - через шаблон групповой политики pcoip.adm, про работу с которым написано, например, вот тут. Настройка GPO называется "Configure PCoIP client image cache size policy":
Диапазон допустимых значений - от 50 до 300 МБ. Работает эта штука и для Linux-устройств. С ней есть тоже одна засада - если на тонком клиенте мало оперативной памяти (меньше 1 ГБ), клиентский кэш луше немного уменьшить, если наблюдаются проблемы с производительностью.
Известна также их утилита Virtual Session Indexer (VSI) для тестирования VDI-решений, о которой, собственно, и пойдет речь ниже. На днях коллеги из Login Consultants прислали мне скриншоты и пресс релиз с новой версией VSI 3.6 (см. про 3.5 тут), которая научилась делать Client Side Performance Testing, т.е. тестирование производительности со стороны клиентских устройств для VMware View, Citrix XenDesktop и других решений для виртуализации настольных ПК.
Модуль Client Side Performance Testing теперь может выполнять следующие тесты:
Character response – сколько времени проходит между нажатием кнопки на клавиатуре и прорисовкой на экране с использованием соответствующего протокола передачи (PCoIP, HDX и др.)
Large text response – то же самое, но для больших объемов текста
Mouse click feedback – то же самое, но для щелчка мыши
Image quality and loading times – необходимое время для прорисовки сложной картинки посредством тестируемого.
Картинка непростая - она, ко всему прочему, позволяет заценить еще и качество отображения:
Утилита Login VSI 3.6 позволяет проводить тесты VDI-нагрузок для следующих сценариев:
Что будет, если увеличить число пользователей на сервер, как изменится поведение рабочего стола на клиенте?
Если переключиться с Server Side на Client Side rendering, какое влияние будет на потребление канала и отклик для пользователя?
Какой эффект оказывает WAN-акселератор (если он есть) на производительность сессии с виртуальным ПК?
В первой части статьи "Сравнение производительности StarWind iSCSI Enterprise и Microsoft iSCSI" мы приводили выводы Джейка Ратски о том, что iSCSI-таргет от компании StarWind показывает большую производительность по сравнению с его аналогом от Microsoft для рассмотренной нагрузки при установке одной ВМ. Теперь Джейк провел тестирование обоих продуктов при использовании трех виртуальных машин (на той же самой конфигурации оборудования), с которым можно ознакомиться в следующих статьях:
Для тех, кто использует хранилища iSCSI под виртуальные машины - очень полезно ознакомиться. Приведем основные выводы.
1. Использование полосы пропускания адаптера iSCSI.
Microsoft iSCSI:
StarWind iSCSI:
Как видно из картинок, StarWind iSCSI потихоньку разгоняется и показывает лучшие результаты, чем Microsoft iSCSI Target. Происходит это за счет активного использования кэша на сервере хранилища iSCSI, как и в предыдущем тесте:
2. Эффективность процесса дедупликации.
Как мы уже писали, StarWind iSCSI использует inline-дедупликацию данных на хранилище с размером блока 4 КБ, что подразумевает запись на диск только оригинальных копий данных, без повторяющихся блоков. В тесте для 3-х ВМ размером 9 ГБ каждая на хранилище было реально занято 8,69 ГБ данных, что довольно эффективно для трех практически одинаковых машин.
Коэффициент дедупликации - 3.15 к 1.
3. Производительность хранилища.
В тесте опять использовалась нагрузка, генерируемая IOMeter, на одной машине при двух простаивающих, а также на всех трех одновременно. Результат MS iSCSI (нагружена только одна ВМ):
Результат StarWind iSCSI:
И тут снова StarWind выигрывает.
Теперь метрики IOMeter для трех одновременно нагруженных ВМ для Microsoft iSCSI (минута с момента начала генерации нагрузки):
RSS
